home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 6734 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  2.0 KB
  1. Path: news.ios.com!usenet
  2. From: larrymb@gramercy.ios.com (Pacarana)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: AddIntServer + VERTB strangeness
  5. Date: 1 Apr 1996 22:40:17 GMT
  6. Organization: Internet Online Services
  7. Message-ID: <1550.6665T972T1664@gramercy.ios.com>
  8. References: <199603201423.OAA59524@poseidon.bfs.unibol.com><1011.6654T1057T1918@gramercy.ios.com> <PETERM.96Apr1101437@tui.maths.irl.cri.nz>
  9. NNTP-Posting-Host: ppp-53.ts-6.hck.idt.net
  10. X-Newsreader: THOR 2.22 (Amiga;TCP/IP) *UNREGISTERED*
  11.  
  12. >larrymb@gramercy.ios.com Pacarana writes:
  13. >>   Well there isn't any point to using a mix of OS calls and direct hardware
  14. >>coding. That's the most dangerous way to do thingsand the most prone to
  15. >>failure.
  16. >On the contrary, the safest method of direct hardware programming is
  17. >to check for and exclusively allocate the particular hardware
  18. >component via OS calls, then directly access that hardware.  Use
  19. >high-level OS calls for everything not exclusively allocated at the
  20. >lowest level.
  21.   Yes, and that's actually exactly what I meant. By mixing I meant using a mix
  22. of OS and hardare gfx/audio/interrupt commands. Any sort of mish-mash where
  23. you might use actually commands that carry out things and don't just allocate
  24. or inform, mixed with direct hardware access is dangerous. I didn't mean to
  25. say that mixing AllocMem,OwnBlitter type calls with direct programming is
  26. dangerous.
  27.  
  28. >What doesn't work is killing the entire OS (e.g, by breaking OS rules)
  29. >and then expecting OS calls to work.
  30.   Certainly, I agree with this.
  31.  
  32. >There is no safe way to temporarily take-over and restore the entire
  33. >OS.
  34.   Well, in my terminology using Disable/Forbid/OwnBlitter/etc. then your
  35. direct hardware stuff is called temporarily taking over the OS. I think we
  36. just have our terms crossed here. I didn't mean to say that you could start
  37. using memory without AllocMem, take over the interuppts and copper or what not
  38. and then start calling OS calls at random or expect to be able to safely
  39. return to WB afterwards (if you did the absolute mem grab type stuff).
  40.  
  41.